Those skilled in the art of IP telephony are well aware that “The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences,” (See Request for Comments: 3261 (RFC 3261 at http://tools.ietf.org/html/rfc3261) from the Internet Engineering Task Force (“IETF”) www.ietf.org) SIP can provide a signaling and call setup protocol for IP-based communications able to support at least some of the call processing functions and features of the public switched telephone netvork (“PSTN”) as well as many advanced Web-based features.
Much work has been done on SIP since RFC 3261. See for example the Internet-draft entitled A Framework for Session Initiation Protocol User Agent Profile Delivery at http://tools.ietf.org/html/draft-ietf-sipping-config-framework-12 by Petrie et al. (“Petrie”). Petrie describes configuration scenarios for a number of important system architectures (See for example “Simple Deployment Scenario” Section 4.1 of Petrie and “Device supporting multiple users from different Service Providers” Section 4.2 of Petrie). These scenarios are all addressed from the viewpoint and necessary relationships for the end point being configured and simplifying assumptions are made regarding availability of configured network elements to assist in the process.
There are many shortcomings to Petrie for at least some applications and environments. Petrie does not discuss necessary relationships between the configuration servers shown in FIG. 1 of Petrie and the business entities supplying them. Importantly, Petrie: a) assumes specifically configured network infrastructure in the user's location for the end-user devices (end points) to become configured, b) assumes a prior relationship between the user's network or that of their access provider and either the device provider (i.e. the device vendor) or the service provider (i.e. the provider of the voice or other media communication service), and c) does not allow for end points to be directed to one of many possible service providers based on devices manufactured or distributed by a single device vendor.
Petrie is also not generally suitable for configuration of a Voice over IP (“voIP”) network in a residential or small business establishment, and is not readily applicable to remote and branch office, as well as teleworking scenarios in a larger enterprise. Petrie assumes that the local network is managed by trained personnel, which is something that cannot be assumed for the home or small office market, nor can it be assumed in smaller branch offices of a larger enterprise.
Petrie describes three sources of configuration information as shown in FIG. 1 of Petrie. The SIP Service Provider supplies information (feature subscriptions etc) that is specific to the individual user. The Device Provider provides information that is specific to the device. The Local Network Provider provides information that guides the device in the use of the local network. Petrie assumes that the local network is owned by the provider of this information and will set constraints on its use (e.g. bandwidth limitations on a local WiFi hot spot in a coffee shop).
Section 5.1.1.1 of Petrie describes in considerable detail how the device will obtain the required local network configuration profile. This will be obtained from a local Dynamic Host Configuration Protocol (“DHCP”) server or through the use of a locally relevant Domain Name Service (“DNS”), The local DHCP and DNS server in Petrie will, in practice, need to be updated by trained personnel. No such personnel can be assumed to exist in the small business, home or small branch office markets.
Section 5.1.1.2 and its subsections of Petrie describe similar processes for obtaining a device configuration profile. Again, assumptions are made regarding the availability of configured network resources to assist in this process that are invalid for small unmanaged network environments or impose significant deployment constraints on their applicability. In the case of device profiles, multiple possible methods are described in Petrie.
In the first method, service provider or device manufacturer pre-configured information is used to locate the device profile server, which is functional, however presumes a pre-existing relationship between the device manufacturer and service provider in order to bring the device fully into service. No such relationship may exist, or multiple such relationships may exist (one device provider to many possible service providers, or many device providers to one service provider), either of which is ambiguous, hence final configuration cannot be immediately completed.
In a second method, it is assumed that a device profile can be located using the local network domain (supplied by DHCP) to locate the device profile server, i.e. the device profile server is in the provided local domain. Either in the local network or in the access network (e.g. the Internet Service Provide (“ISP”)), both DHCP and DNS servers would need to be configured to provide correct information for the location of the device profile server. This assumes there is a pre-existing relationship either between the local network administrator and the entity that manages the device profile server (likely the local network is effectively unmanaged in a small network environment), or there is a relationship between the user's access network (e.g. ISP) and that entity—no such relationships can be assumed (i.e. the network access and device maintainer are not in general related to each other in any way).
The third method is manual configuration, which implies some level of user knowledge and interaction, and is not auto-configuration at all.
In general, Petrie is not adequate for the small business and home systems of interest to this disclosure, and is also not readily applicable to a wide range of branch office and teleworking scenarios in larger enterprises. Petrie assumes that the local network will be of some sophistication. Petrie assumes that the local network has been configured with a domain identifier for example. Petrie assumes that the local DHCP server has been set up to contain this information. Pertinent to this is the implicit assumption that there are personnel responsible for the site that have the skills to set up a DHCP and/or DNS servers in specifically required ways.
Petrie also assumes a pre-existing relationship between local network and the entity which maintains the device profile server, or between the user's access network and that entity. While sometimes viable (e.g. the ISP is also the device maintainer and the voice service provider), these assumptions are not true in the general case (all three entities may be unrelated). Even if such relationships could be set up, they would grow extremely complex and onerous over time, due to the highly distributed, global, and ever changing nature of Internet-based systems.
Further to this, Petrie assumes that the local network is supplied with a SIP proxy server which is able to handle issues with firewall and Network Address Translation (“NAT”) in order to make contact with outside SIP facilities. This will also not be true in the general case, particularly in home and small business environments.
In the home and small business situation, none of these assumptions are necessarily valid. The operative assumption is that a naïve user will buy a device (SIP telephone etc.) at a consumer-level store (e.g. big box electronics outlet), or be shipped a generic device by a service provider or device provider, take it home or to the small business, and plug it into their own network. They will expect the device to function as intended without delay and without any training that cannot be obtained from a brief instruction sheet. Any requirement that the user possess or obtain specialized skills will make these devices commercially unattractive.
In addition to the requirements on the local network, Petrie is silent on how the location of the SIP Service provider configuration server is found. It is assumed that this is somehow configured.
A problem addressed by Peterie is the configuration of SIP User Agents (UA) (devices such as IP telephones, softphone clients on PCs etc), Petrie envisages this to be taking place on the LAN within a business or other institution, in residential small networks, or in public “hotspots” and similar. When these devices are first installed, they must be supplied with some initial configuration information. This can include (not limited to): An updated software load; Initial configuration of soft keys and other optional controls and displays and importantly for this disclosure, the location of the SIP proxy server. Petrie calls this the Discovery and Enrollment phases. The UAs will receive most of their configuration information by use of SIP Subscribe/Notify interactions with the configuration server shown FIG. 1 of the Petrie draft. The Petrie Draft recommends that this server be given the well-known SIP user id of “_sipuaconfig”. They will issue Subscribe messages for their desired configuration and receive them by the corresponding Notification.
This interaction requires that the UAs be aware of the address and port of the Configuration Server. Petrie describes several possible methods including manual loading. However, the method that Petrie foresees as being most commonly used is that of DHCP. DHCP is commonly used to provide UAs with the address of the SIP Proxy server (logically different from and not necessarily the same as the desired configuration server). The port number used on the Proxy server may be added to the DHCP server as an optional extension. With the address of the proxy server, the port number and the well-known user id of the configuration server, the configuration server's SIP URI can be constructed. A similar alternate to this uses DNS lookup, based on DHCP-supplied “local domain”, to attempt to locate the desired configuration server in the local domain. With this information the UAs can attempt to interact with the Configuration Server.
The Petrie solution is characterized by:                Taking place in the LAN environment (behind the firewall and/or NAT) of a single enterprise or institution, or in some other managed environment,        The local network is prepared for its operation in that the DHCP and DNS servers are configured to supply the proper information and that a configuration server is supplied and properly registered with the locally known SIP proxy.        There are trained personnel servicing the network. For example, to update the DHCP server with the optional extension including the port address of the Proxy server and/or DNS entries for the configuration server, and to ensure the configuration server is known to the Proxy server.        The devices on the LAN have been configured by a single entity (a single vendor such as the local system manager, a value-added reseller or a manufacturer) and as such are adapted to work together.        If the configuration server is in a foreign network (not the same as the local network), information for the configuration server can be known to the local administration, and can be configured successfully in the local network, or is configured in the access network to which the local network is connected. This assumes a prior arrangement between the local or access network and the network(s) hosting the configuration servers.        
There are several drawbacks and limitations to this approach, as discussed above and there are other drawbacks and limitations that will now occur to those skilled in the art.
Current VoIP service providers such as Vonage or Skype use proprietary devices. Vonage supplies a specific piece of hardware that connects standard telephones to its VoIP network, Skype supplies a software client that operates on standard personal computers. However these solutions are operable on only the networks supplied by these providers. The systems are self-configuring because of this limitation. One deficiency of these systems is that users cannot buy equipment from a provider of their choice and attach it to these networks,